Subject: BOOPSI Object Streams (BOS) URL X-Homemail: mailto:efp90@nuke.dircon.co.uk X-Url: http://www.users.dircon.co.uk/~nuke/ Resent-Message-Id: <"IM02Z3.0.x25.IKiin"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List:archive/latest/1472 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE X-Lines: 17 Status: RO Content-Type: text/plain Content-Length: 452 Hi, Following on from the `Method madness: the Truth' discussion and my `spouting off' I've prepared a Web page for my BOOPSI Object Streams stuff: http://www.users.dircon.co.uk/~nuke/BOS.html It's basically just a pretty good explaination at the moment, but I'm still hoping to let people at this stuff mid-June; this will be the mail-list and that is the page where you can hear about it first... Thanks to those who've shown interest!! Ellis. Subject: Re: BOOPSI Object Streams (BOS) URL References: X-Homemail: mailto:efp90@nuke.dircon.co.uk X-Url: http://www.users.dircon.co.uk/~nuke/ Resent-Message-ID: <"ll7Uo1.0.AT6.t5Ojn"@susi> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de X-Mailing-List: archive/latest/1484 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de X-Lines: 70 Status: RO Content-Type: text/plain Content-Length: 2821 Hi Hans, > My Garbage Collector have an ID allocater so that every object > gets an unique ID. I can then save the object on a stream like > this: > > ------------ > | ID | -> Objects unique ID, I can allways find it. > ------------ > | Size | -> Size of all data below (It's not an IFF :) > ------------ > | Class ID | -> Then we know what class to create. > ------------ > | Object | -> Whatever data the object wants to have saved. > | data | > ------------ > > This way an object can tell the streamobject to save or - if there > allready is one on the stream with the same ID - overwrite it. > Also a containerobject could use the unique ID's to keep track of > the objects it contains if it where to be saved on the stream. Probably not... if I've understood you correctly! The `id' is basically the address of the object; on store, when the Stream class receives the MUIM_Stream_StoreObj method it first looks up the address of the object in a stream-private table; if it is not found then it makes an entry, generating a unique id on the fly (actually the index into the table) and writes the class data; if it is found then it just writes the id. On ReadObj the Stream object will either get an `object is coming' delimiter or an `object reference is coming' delimiter from the stream, if this is an `object is coming` then it looks up the class and calls NewObject(); the class's ReadFrom method has to take care of making sure that it is entered into the `load-table' for multiple-reference resolving which it does by calling MUIM_Stream_RefReadObj as soon as it gets an Object * from it's ultimate `BOS-unaware' baseclass (i.e. for a fully BOS class at the level above `rootclass' and for a `built-on' class at the first level which knows about BOS). The Object * is then in the `load-table' and subsequently when the stream reads a `object reference is coming' delimiter it can read the id from the stream and simply index into the load-table to find the pointer it should return. This works!! I have code *now* using this stuff, it's also not a new idea: our streaming stuff here at CAS works exactly this way; I should know since I've re-coded this mechanism recently to make it thread-safe (BOS is thread safe already!). Hope I've understood what you meant! :*) Anyway, the garbage collection stuff might be useful, did you say this was for BOOPSI or what? Incidentally, since you mention prefs, one of my example classes is actually a preferences management class; you can add `Tagged' preferences entries into this dataspace which can either be a pure numerical value, a simple string or an Object, and save and restore the whole lot using BOS. I was going to keep this for myself :*), but I may well release this too if people can find a use for it! Ellis. Subject: Re: BOOPSI Object Streams (BOS) URL References: X-Homemail: mailto:efp90@nuke.dircon.co.uk X-Url: http://www.users.dircon.co.uk/~nuke/ Resent-Message-ID: <"napKp1.0.8s4.7Fgjn"@susi> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.de Reply-To: mui@sunsite.Informatik.RWTH-Aachen.de X-Mailing-List: archive/latest/1494 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.de X-Lines: 45 Status: RO Content-Type: text/plain Content-Length: 1709 Hi Hans, > I don't see how you can make the index a unique ID? What if you > remove an object from the mittle of the stream wouldn't this > happen: > > 1 2 3 4 5 6 7 8 // ID's as indexes. Now we remove object > // with ID 4. > 1 2 3 5 6 7 8 // and create a new object > 1 2 3 5 6 7 8 8 // giving 2 objects with same ID. > > I'm getting this right? I would like to have some smart ways of > allocating ID's. There is no provision for `removing an object from the middle of a stream'; basically the whole lot gets streamed, or none of it... This is purely an archive/un-archive mechanism. > > Anyway, the garbage collection stuff might be useful, did > > you say this was for BOOPSI or what? > > It's not for BOOPSI, but it should not be hard to make it so. > Please be more specific about what in the garbage collection > stuff could be usefull. I think BOS has it all covered, though > I'm not totally sure. BOS is only a system for object storage, it doesn't encompass garbage collection; that sort of mechanism is quite useful when you are throwing around alot of objects without any kind of true `ownership'... at some point the object is no longer refered to by anyone, so it gets `collected'. Of course in the common case this situation does not arise; you know what object owns something and whos responsibilty it is to delete it; but it might be an interesting project! > Well to save the whole lot is not that hard. MUI is allready doing > it for some parts. It's the restoring last saved for a single > object and save a single object in a big prefs file that is the > hard part. Pushing one big application structure to the disk and > back again is not that hard. Sure. Ellis.